Database applications are commonly used to store large amounts of data. Modern databases often also track metadata, or data about the data, to further improve storage capabilities and searchability. Users may access the databases for a variety of different uses, but one popular use is to generate reports based on the data and metadata in a database.
Online Analytical Processing (OLAP) involves the use of computers to extract useful trends and correlations from large databases of raw data. It may involve consolidating and summarizing huge databases containing millions of items (e.g., sales figures from all branches of a supermarket chain) and making this data viewable along multidimensional axes, while allowing the variables of interest to be changed at will in an interactive fashion. As such, the processing and memory load on OLAP servers is very high.
FIG. 1 is a diagram illustrating a typical OLAP architecture. Here, one or more OLAP servers 100 may receiver queries from users 102 via an application program interface (API) 104, generally associated with what is called a thick spreadsheet add-in (a program that sits atop a spreadsheet program). The term “thick” implies that the add-in is relatively large, such as one that requires a lot of overhead, as opposed to a “thin” add-in which uses minimal overhead. The add-in may utilize the user-interface of the spreadsheet to receive a data query and/or identification of metadata 106 from the user 102. It may then process this query and issue its own query 108 to an appropriate OLAP server. This query 108 is typically in the form of a complete grid of all metadata the user was able to view, along with an indication of actions the user wishes to take on the metadata (e.g., “drill-down”).
There are, however, several drawbacks to this approach. First, grids of all available metadata can often be quite large. Typically users will not need all that information. For example, most systems only allow a limited amount of data to be displayed on the screen at once. While the processing power required on the user's side to handle such large grids may be adequate, the OLAP server must process many of these grids per second, slowing down its operation. Additionally, since these grids are often quite large, they can take up a significant portion of memory. It would therefore be more beneficial if there was a way to limit the query 108 to only the most vital information.
Second, current OLAP servers function in a session environment. This means that the user begins a session with the OLAP server (via the API) and that particular OLAP server continues to serve the user until the session is terminated. With multiple queries coming in from multiple users, it can become quite common for one OLAP server to be overloaded while others have available resources. While load balancing can be performed between OLAP servers, past solutions have all required the OLAP server to make this determination. For example, an OLAP server that is overloaded might check to see if it can find other OLAP servers to whom to pass off some work. This determination, however, merely uses up valuable processing power in the OLAP server. Additionally, those solutions require that the entire grid be passed to the initial OLAP server, creating the memory problem described above. What is needed is a solution that allows for load balancing without requiring additional processing power or memory from the OLAP server.
Third, many users may not wish to use up valuable processing power on their machine to support a thick spreadsheet add-in. What is needed is a solution that utilizes thin spreadsheet add-ins.